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DETAILED ACTION 

1 . Claims 1-23 are pending in this examination. 

Allowable Subject Matter 

2. Claim 19 would be allowable if rewritten in independent form including all of the 
limitations of the claims 20, 21 , 22, and 23. 

Information Disclosure Statement 

3. The IDS dated 8/1 1/08, 6/19/06, 6/6/05 and 1/2/04 has been considered. See 
PTO-1449. 

Claim Rejections - 35 USC § 101 

35 U.S.C. 101 reads as follows: 

Whoever invents or discovers any new and useful process, machine, 
manufacture, or composition of matter, or any new and useful improvement 
thereof, may obtain a patent therefor, subject to the conditions and requirements 
of this title. 

Claims 1-18 are rejected under 35 U.S.C. 101 because the claimed invention is 
directed to non-statutory subject matter. 

4. Referring to claims 1, 6, 13 and 16 the claim recites, "PeerName managed class 
comprising a peer name string property field, an authority field, a classifier field, and a 
secured field "PeerName managed class" just limited to software modules or block 
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per se, as evidenced by the Specification ([0067]). The claim is not limited to statutory 
subject mater and is therefore nonstatutory. 

5. Likewise, claims 2-5, 7-1 2, 1 4-1 5, 1 7 and 1 8 are dependent claims that depend 
on claims 1,6, 13 and 16 and fail to resolve the above problems, therefore, claims 2-5, 
7-12,14-15, 17 and 18 are also rejected under 35 U.S.C 101. 



Claim Rejections - 35 USC §112 

The following is a quotation of the first paragraph of 35 U.S.C. 112: 

The specification shall contain a written description of the invention, and of the manner and process of 
making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the 
art to which it pertains, or with which it is most nearly connected, to make and use the same and shall 
set forth the best mode contemplated by the inventor of carrying out his invention. 

6. The specification is objected to under 35 U.S.C. 1 1 2, first paragraph, as failing to 
adequately teach how to make an/or use the invention. The specification is enabling for 
a portion of the subject matter claimed but the enablement is not commensurate in 
scope with the claim. Specifically, the specification fails to show how the single step of 
"managed class. . ." of the claim can perform the claimed functions. Thus, it would 
require undue experimentation for a person having ordinary skill in the pertinent art to 
make and use the invention as disclosed and claimed. 

Claims 1-18 are rejected under 35 U.S.C. 1 12 first paragraph, for the reasons set 
forth in the objection to the specification. See In re Hyatt 218 USPQ 195 (CAFC 1983). 
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The following is a quotation of the second paragraph of 35 U.S.C. 112: 

The specification shall conclude with one or more claims particularly pointing out and distinctly 
claiming the subject matter which the applicant regards as his invention. 

7. Claims 1 -1 8 are rejected under 35 U.S.C. 1 1 2, second paragraph, as being 
indefinite for failing to particularly point out and distinctly claim the subject matter which 
applicant regards as the invention. Claim language is very unclear and indefinite to 
understand the claimed subject matter. 

Claim Rejections - 35 USC § 103 

The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 102 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

Claims 1-23 are rejected under 35 U.S.C. 103(a) as being unpatentable over Pabla et 
al. (herein after Pabla) U.S. PGPub No.: 20040064693, in view of Joseph Mayo, C# 
Unleashed, Volume 2002, Pub. Date: November 14, 2001, ISBN-1 0:0-672-321 22-X. 

8. Referring to claim 1, Pabla discloses a PeerName managed class comprising a 
peer name string property field, an authority field, a classifier field, and a secured field 
(figs. 9-1 1 , [001 5], user name, peer identifier and/or name, a password, certificate, and 
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other authentication information and usage information. Identity information such as 
user names, peer identifiers and/or names, passwords, certificates and associated 
information may be stored in a distributed index, also see [0070], [0085], [0087], [0098- 
0099] , [0323] , [0332-0333] , [0469-0471 ],[061 7]). 

Pabla does not explicitly disclose class as a code format. However, Mayo 
discloses class as a code format (pages 86 and 124). 

It would have been obvious to one of ordinary skill in the art at the time of 
invention to combine the teaching of Pabla with the teaching of Mayo by including the 
feature of class as a code format, in order for Pabla's system to able to use 
programming codes to manage peer-to-peer network as a result all computers share 
responsibility, which may include bandwidth, storage space, and computing power and 
avoid central database thereby increasing user desirability of use. 

Referring to claim 2, Pabla discloses the PeerName managed class of claim 1, 
further comprising a first PeerName constructor to allow an application to specify the 
entire PeerName [0335], constructor, also see [0015] , [0070], [0085], [0087], [0098- 
0099] , [0323] , [0332-0333] , [0469-0471 ] ,[061 7]). 

Referring to claim 3, Pabla discloses the PeerName managed class of claim 1, 
further comprising a second PeerName constructor to allow an application to specify 
a PeerName based on peer identity information and a classifier to allow resolution of 
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the PeerName to a third party [0015], peer identifier, also see 

[0070] , [0085] , [0087] , [0098-0099] , [0323] , [0332-0333] , [0469-047 1 ] , [06 1 7] ) . 

Referring to claim 4, Pabla discloses the PeerName managed class of claim 1, 
further comprising a third PeerName constructor to allow an application to specify a 
PeerName based on a PeerName object and a classifier to allow resolution of the 
PeerName to a third party ([0016], peer group membership, also see [0015], 
[0070] , [0085] , [0087] , [0098-0099] , [0323] , [0332-0333] , [0469-047 1 ] , [06 1 7] ) . 

Referring to claim 5, Pabla discloses the PeerName managed class of claim 1, 
further comprising at least one method exposed thereby selected from the group 
consisting of an equals method, ==method, a GetHashCode method, a GetType 
method, a ReferenceEquals method, and a ToString method ([0015], hash, also see 
[0070], [0085], [0087], [0098-0099], [0323],[0332-0333],[0469-0471], [061 7]). 

Referring to claim 6, Pabla discloses a Peerldentity managed class comprising a 
PeerName field, a FriendlyName field, and a Key field ([0015], user name, peer 
identifier and/or name, a password, certificate, and other authentication information 
and usage information. Identity information such as user names, peer identifiers 
and/or names, passwords, certificates and associated information may be stored in 
a distributed index, also see [0070], [0085], [0087], [0098-0099], [0323], [0332- 
0333],[0469-0471],[0617]). 
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Pabla does not explicitly disclose class as a code format. However, Mayo 
discloses class as a code format (pages 86 and 124). 

It would have been obvious to one of ordinary skill in the art at the time of 
invention to combine the teaching of Pabla with the teaching of Mayo by including the 
feature of class as a code format, in order for Pabla's system to able to use 
programming codes to manage peer-to-peer network as a result all computers share 
responsibility, which may include bandwidth, storage space, and computing power and 
avoid central database thereby increasing user desirability of use. 

Referring to claim 7, Pabla discloses the Peerldentity managed class of claim 6, 
further comprising a first constructor to retrieve an identity based on a PeerName 
parameter ([0016], find corresponding identity information, also see[0015] , 
[0070], [0085], [0087], [0098-0099], [0323], [0332-0333], [0469-0471], [0617]). 

Referring to claim 8, Pabla discloses the Peerldentity managed class of claim 6, 
further comprising a second constructor to create a new identity based on a 
friendlyName parameter, a classifier, and a key ([0015], the user identity may be 
added to the distributed index by adding identity information to the distributed index 
at the location of the distributed index corresponding to the hash of the user identity, 
also see [0070], [0085], [0087], [0098-0099], [0323], [0332-0333], [0469-0471 ], [061 7]). 
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Referring to claim 9, Pabla discloses the Peerldentity managed class of claim 6, 
further comprising a third constructor to create a new identity based on friendlyName 
parameter and a classifier ([0352] create modules with a similar functionality, also 
see [001 5], [0070],[0085], [0087], [0098-0099], [0323], [0332-0333], [0469- 
0471], [0617]). 

Referring to claim 10, Pabla discloses the Peerldentity managed class of claim 6, 
further comprising a fourth constructor to create a new identity based on a 
friendlyName parameter, a blank classifier, and a new key pair ([0352] create 
modules with a similar functionality, also see [0015], [0070], [0085], [0087], [0098- 
0099] , [0323] , [0332-0333] , [0469-0471 ] ,[061 7]). 

Claim 1 1 , is rejected for similar reasons as stated above. 

Referring to claim 12, Pabla discloses the Peerldentity managed class of claim 6, 
further comprising at least one static method exposed thereby selected from the 
group consisting of a Getldentities static method, a first import static method utilizing 
an Exported Peerldentity and a password to import a Peerldentity, and a second 
import static method utilizing an Exported IdentityXml string and a password to import 
a Peerldentity ([0127], multi-platform, secure execution environment, also see 
[00 1 5] , [0070] , [0085] , [0087] , [0098-0099] , [0323] , [0332-0333] , [0469-0471 ] , [06 1 7] ) . 
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Referring to claim 13, Pabla discloses a Peerldentitylnfo managed class comprising 
a PeerName field, a FriendlyName field, and a Key field ([0015], the user identity 
may be added to the distributed index by adding identity information to the 
distributed index at the location of the distributed index corresponding to the hash of 
the user identity, also see [0070], [0085], [0087], [0098-0099],[0323], [0332- 
0333],[0469-0471],[0617]). 

Pabla does not explicitly disclose class as a code format. However, Mayo 
discloses class as a code format (pages 86 and 124). 

It would have been obvious to one of ordinary skill in the art at the time of 
invention to combine the teaching of Pabla with the teaching of Mayo by including the 
feature of class as a code format, in order for Pabla's system to able to use 
programming codes to manage peer-to-peer network as a result all computers share 
responsibility, which may include bandwidth, storage space, and computing power and 
avoid central database thereby increasing user desirability of use. 

Referring to claim 14, Pabla discloses the Peerldentitylnfo managed class of claim 
13, further comprising a Peerldentitylnfo constructor that constructs a 
Peerldentitylnfo object from an IdentitylnfoXml string ([0352] create modules with a 
similar functionality, also see [0015], [0070], [0085], [0087], [0098-0099],[0323], [0332- 
0333],[0469-0471],[0617]). 

Claim 15, is rejected for similar reasons as stated above. 
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Referring to claim 16, Pabla discloses an Exported Peerldentity managed class 
comprising an ExportedPeerldentity constructor that utilizes an 
Exported IdentityXmlString to construct an ExportedPeerldentity object (figs. 9-1 1 , 
[0015], user name, peer identifier and/or name, a password, certificate, and other 
authentication information and usage information. Identity information such as user 
names, peer identifiers and/or names, passwords, certificates and associated 
information may be stored in a distributed index, also see [0070], [0085], [0087], [0098- 
0099] , [0323] , [0332-0333] , [0469-0471 ] ,[061 7]). 

Pabla does not explicitly disclose class as a code format. However, Mayo 
discloses class as a code format (pages 86 and 124). 

It would have been obvious to one of ordinary skill in the art at the time of 
invention to combine the teaching of Pabla with the teaching of Mayo by including the 
feature of class as a code format, in order for Pabla's system to able to use 
programming codes to manage peer-to-peer network as a result all computers share 
responsibility, which may include bandwidth, storage space, and computing power and 
avoid central database thereby increasing user desirability of use. 

Referring to claim 17, Pabla discloses the ExportedPeerldentity managed class of 
claim 16, further comprising a PeerName property that returns the PeerName of the 
exported identity ([0352] create modules with a similar functionality, also see [0015], 
[0070] , [0085] , [0087] , [0098-0099] , [0323], [0332-0333] , [0469-047 1 ] , [06 1 7] ) . 
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Claim 18, is rejected for similar reasons as stated above. 

Referring to claim 19, Pabla discloses a method of managing by an application a 
PeerName in a managed framework, the method comprising the steps of: 
communicating with a managed PeerName object, the managed PeerName object 
exposing constructors for creating an entire PeerName object, creating a 
hypothesized PeerName object for resolution to a third party from Peerldentitylnfo 
and a classifier, and creating a second hypothesized PeerName object for resolution 
from a known PeerName object; selecting one of the constructors; passing to the 
managed PeerName object parameters required by the constructor selected; and 
initiating the constructor ([0065] A first peer may initially handle all the space in the 
distributed index. When another peer joins the distributed index, the distributed index 
may be split between the two peers to create two spaces or zones of the distributed 
index, also see [0015], [0070], [0085], [0087] ,[0098-0099], [0323], [0332-0333], [0469- 
0471], [0617]). 

Pabla does not explicitly disclose class as a code format. However, Mayo 
discloses class as a code format (pages 86 and 124). 

It would have been obvious to one of ordinary skill in the art at the time of 
invention to combine the teaching of Pabla with the teaching of Mayo by including the 
feature of class as a code format, in order for Pabla's system to able to use 
programming codes to manage peer-to-peer network as a result all computers share 
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responsibility, which may include bandwidth, storage space, and computing power and 
avoid central database thereby increasing user desirability of use. 

Referring to claim 20, Pabla discloses the method of managing by an application a 
Peerldentity in a managed framework, the method comprising the steps of: 
communicating with a managed Peerldentity object, the managed Peerldentity 
object exposing constructors for creating a new identity from parameters of 
FriendlyName, classifier, and key, for creating a new identity from parameters of 
FriendlyName and classifier, for creating a new identity from parameters of 
FriendlyName, a blank classifier, and a new key pair, and retrieving an identity 
associated with a given PeerName parameter; selecting one of the constructors; 
passing to the managed Peerldentity object parameters required by the constructor 
selected; and initiating the constructor ([0352] create modules with a similar 
functionality, also see [0015], [0070], [0085],[0087],[0098-0099], [0323], [0332- 
0333],[0469-0471],[0617]). 

Pabla does not explicitly disclose class as a code format. However, Mayo 
discloses class as a code format (pages 86 and 124). 

It would have been obvious to one of ordinary skill in the art at the time of 
invention to combine the teaching of Pabla with the teaching of Mayo by including the 
feature of class as a code format, in order for Pabla's system to able to use 
programming codes to manage peer-to-peer network as a result all computers share 
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responsibility, which may include bandwidth, storage space, and computing power and 
avoid central database thereby increasing user desirability of use. 

Referring to claim 21, Pabla discloses the method of claim 20, wherein the managed 
Peerldentity object further exposes static methods for importing a peer identity from 
an Exported Peerldentity and a password, for importing a peer identity from an 
Exported IdentityXml string and a password, and for retrieving a collection of 
identities for a user account, the method further comprising the steps of selecting 
one of the static methods, passing to the managed Peerldentity object parameters 
required by the static method, and initiating the static method (figs. 9-11, [0015], 
user name, peer identifier and/or name, a password, certificate, and other 
authentication information and usage information. Identity information such as user 
names, peer identifiers and/or names, passwords, certificates and associated 
information may be stored in a distributed index, also see 
[0070], [0085], [0087], [0098-0099], [0323],[0332-0333], [0469-0471], [0617]). 

Referring to claim 22, Pabla discloses a method of managing by an application 
Peerldentitylnfo in a managed framework, the method comprising the steps of: 
communicating with a managed Peerldentitylnfo object, the managed 
Peerldentitylnfo object exposing a constructor for creating a Peerldentitylnfo object 
from an IdentitylnfoXml parameter; passing to the managed Peerldentitylnfo object 
the parameter required by the constructor; and initiating the constructor ([0352] 
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create modules with a similar functionality, also see [0015], 

[0070] , [0085] , [0087] , [0098-0099] , [0323] , [0332-0333] , [0469-047 1 ] , [06 1 7] ) . 

Pabla does not explicitly disclose class as a code format. However, Mayo 
discloses class as a code format (pages 86 and 124). 

It would have been obvious to one of ordinary skill in the art at the time of 
invention to combine the teaching of Pabla with the teaching of Mayo by including the 
feature of class as a code format, in order for Pabla's system to able to use 
programming codes to manage peer-to-peer network as a result all computers share 
responsibility, which may include bandwidth, storage space, and computing power and 
avoid central database thereby increasing user desirability of use. 

Referring to claim 23, Pabla discloses a method of managing by an application a 
Exported Peerldentity in a managed framework, the method comprising the steps of: 
communicating with a managed Exported Peerldentity object, the managed 
Exported Peerldentity object exposing a constructor for creating an 
Exported Peerldentity object from an ExportedldentityXmlString; passing to the 
managed ExportedPeerldentity object parameters required by the constructor; and 
initiating the constructor ([0352] create modules with a similar functionality, also see 
[0015], [0070],[0085],[0087],[0098-0099],[0323],[0332-0333],[0469-0471],[0617]). 

Pabla does not explicitly disclose class as a code format. However, Mayo 
discloses class as a code format (pages 86 and 124). 
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It would have been obvious to one of ordinary skill in the art at the time of 
invention to combine the teaching of Pabla with the teaching of Mayo by including the 
feature of class as a code format, in order for Pabla's system to able to use 
programming codes to manage peer-to-peer network as a result all computers share 
responsibility, which may include bandwidth, storage space, and computing power and 
avoid central database thereby increasing user desirability of use. 

Conclusion 

9. The prior art made of record and not relied upon is considered pertinent to 
applicant's disclosure. 

1 0. Examiner's Note: Examiner has cited particular columns/paragraphs/pages 
and line numbers in the references as applied to the claims above for the 
convenience of the applicant. Although the specified citations are representative of 
the teachings of the art and are applied to the specific limitations within the individual 
claim, other passages and figures may apply as well. It is respectfully requested 
from the applicant in preparing responses, to fully consider the references in its 
entirety as potentially teaching of all or part of the claimed invention. 

1 1 . Any inquiry concerning this communication or earlier communications from 
the examiner should be directed to HARUNUR RASH ID whose telephone number is 
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(571)270-7195. The examiner can normally be reached on Monday - Friday 9:00 
AM to 5:00 PM. 

If attempts to reach the examiner by telephone are unsuccessful, the 
examiner's supervisor, Joseph E. Avellino can be reached on 571-272-3905. The 
fax phone number for the organization where this application or proceeding is 
assigned is 571-273-8300. Information regarding the status of an application may be 
obtained from the Patent Application Information Retrieval (PAIR) system. Status 
information for published applications may be obtained from either Private PAIR or 
Public PAIR. Status information for unpublished applications is available through 
Private PAIR only. For more information about the PAIR system, see http://pair- 
direct.uspto.gov. Should you have questions on access to the Private PAIR system, 
contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you 
would like assistance from a USPTO Customer Service Representative or access to 
the automated information system, call 800-786-9199 (IN USA OR CANADA) or 
571-272-1000. 

/H. R.l 

Examiner, Art Unit 2458 



/Joseph E. Avellino/ 

Supervisory Patent Examiner, Art Unit 2458 



